language en

Core Linked.Archi Ontology

Release: 2019-03-17

Modified on: 2026-04-12
This version:
https://meta.linked.archi/core#
Previous version:
https://meta.linked.archi/core/0.3.1#
Revision:
0.3.2
Issued on:
2019-03-17
Authors:
https://linked.zone#me
Kalin Maldzhanski
Publisher:
Linked.Archi
See also:
http://www.iso-architecture.org/ieee-1471/index.html
https://en.wikipedia.org/wiki/ISO/IEC_42010
https://www.wikidata.org/wiki/Q5974096
License:
http://creativecommons.org/licenses/by/4.0/
Visualization:
Visualize with WebVowl
Cite as:
Core Linked.Archi Ontology
Provenance of this page
draft

Core Linked.Archi Ontology: Overview back to ToC

This ontology has the following classes and properties.

Classes

Object Properties

Data Properties

Named Individuals

Core Linked.Archi Ontology: Description back to ToC

Core Linked.Archi Ontology for Enterprise and IT Architecture modeling. Trademarked names (UML, BPMN, ArchiMate, TOGAF, etc.) referenced herein are property of their respective owners.

Cross-reference for Core Linked.Archi Ontology classes, object properties and data properties back to ToC

This section provides details for each class and property defined by Core Linked.Archi Ontology.

Classes

Architecturec back to ToC or Class ToC

IRI: https://meta.linked.archi/core#Architecture

fundamental concepts or properties related to a :System in its environment embodied in its elements, relationships, and in the principles of its design and evolution. Architecture is different form Architecture description as Specified in ISO/IEC/IEEE 42010 Standard. Architecture is an abstract Concept that maps directly to a System of in other words Entity of Interest. Any System has an Architecture whether intentional or accidental, known or unknown, documented or contained as tacit knowledge. Architecture Description (see ISO/IEC/IEEE 42010) is a work product that expresses the architecture. In Linked .Archi context :Model is a more formal specialization of Architecture Description.
is in range of
modelExpressesArchitecture op, stakeholderHasInterestIn op, systemHasArchitecture op

Aspectc back to ToC or Class ToC

IRI: https://meta.linked.archi/core#Aspect

Architecture Aspect example: data, activity, function, location, people, time, motivation, taxonomy, structure, connectivity, behaviour, information, parameters, constraints, roadmaps, traceability, requirements
has super-classes
Consideration c
is in range of
refinedByAspect op, viewpoint covers aspect op

Catalogc back to ToC or Class ToC

IRI: https://meta.linked.archi/core#Catalog

Catalog is a list of building blocks of a specific type, or of related types, that are used for governance or reference purposes (for example, an organization chart, showing locations and actors). As with building blocks, catalogs carry metadata according to the metamodel, which supports query and analysis.
has super-classes
View c

Concernc back to ToC or Class ToC

IRI: https://meta.linked.archi/core#Concern

Example concerns: — The purpose or missions of the system — The appropriateness of the system for use in fulfilling its missions — The feasibility of constructing the system — The risks of system development and operation to users, acquirers, and developers of the system — Maintainability, deployability, and evolvability of the system
has super-classes
Consideration c
is in domain of
refinedByAspect op
is in range of
resultsIn op, stakeholderHasConcern op

Considerationc back to ToC or Class ToC

IRI: https://meta.linked.archi/core#Consideration

Abstract base class for concerns, aspects, and perspectives — the interests that shape how architecture is described and communicated. Subclasses: Concern, Aspect, Perspective.
has sub-classes
Aspect c, Concern c, Perspective c
is in range of
metamodelIdentifiesConsideration op, modelAddressesConsideration op, viewpointFramesConcern op

DeliverableTemplatec back to ToC or Class ToC

IRI: https://meta.linked.archi/core#DeliverableTemplate

A template that defines the content structure of an architecture deliverable by specifying which viewpoints it requires and which presentation formats it supports. Each required viewpoint acts as a placeholder — the actual views are created when someone uses the template to produce a concrete deliverable. A concrete deliverable (arch:Model) is produced by instantiating a DeliverableTemplate: for each required viewpoint, a View conforming to that viewpoint is created and added to the Model via arch:contains.
has super-classes
creative work c
is in domain of
templateHasFormat op, templateHasSection op, templateRequiresViewpoint op, templateTargetsPurpose op
is in range of
deliverableTemplateUsed op, hasDeliverableTemplate op

Diagramc back to ToC or Class ToC

IRI: https://meta.linked.archi/core#Diagram

Diagrams are renderings of architectural content in a graphical format to allow stakeholders to retrieve the required information. Diagrams can also be used as a technique for graphically populating architecture content or for checking the completeness of information that has been collected. The TOGAF content framework defines a set of architecture diagrams to be created (e.g., organization chart). Each of these diagrams may be created several times for an architecture with different style or content coverage to suit stakeholder concerns.
has super-classes
View c

Elementc back to ToC or Class ToC

IRI: https://meta.linked.archi/core#Element

Element is the class for Elements or Nodes used in models. Element sub-classes are to be defined in more specific Architecture Meta Models Element instances are to be used in the actual Architecture Models. In general an Architecture Element represents any significant component of the architecture that needs to be addressed.
has super-classes
ModelConcept c
has sub-classes
Stakeholder c
is in domain of
hasQualityMeasure op, isAbstract dp
is in range of
measuredEntity op

Environmentc back to ToC or Class ToC

IRI: https://meta.linked.archi/core#Environment

The context in which a system exists, including external entities, conditions, and influences that interact with or affect the system. Derived from ISO/IEC/IEEE 42010.
is in range of
environment op

Folderc back to ToC or Class ToC

IRI: https://meta.linked.archi/core#Folder

UI/navigation container used to preserve tool-native organization (containment + stable display order). Not a domain/architecture semantic construct.
has super-classes
item list c

Frameworkc back to ToC or Class ToC

IRI: https://meta.linked.archi/core#Framework

Framework in Linked.Archi context is used to represent any type of Architecture framework. A Metamodel could be defined within a framework and thus part of it example Togaf Content Metamodel or OAF which is mostly a MetaModel or Zachman Framework even an Ontology. Frameworks may define other concepts like Processes, which is the case with Togaf ADM. Framework is characterized with ... check is standard...
has super-classes
creative work c
is in range of
definedByFramework op

Matrixc back to ToC or Class ToC

IRI: https://meta.linked.archi/core#Matrix

Matrix is a grid that shows relationships between two or more model entities. Matrices are used to represent relationships that are list-based rather than graphical in their usage (for example, a CRUD matrix showing which applications Create, Read, Update, and Delete a particular type of data is difficult to represent visually).
has super-classes
View c

Metamodelc back to ToC or Class ToC

IRI: https://meta.linked.archi/core#Metamodel

A Metamodel in Linked.Archi context is the definition (Model) of a Modeling Language, so that models can be expressed in a way that communicates information about a system among involved stakeholders and can be correctly interpreted by those stakeholders and supporting technologies. The Modeling Language formalizes the structure, terms, notations, syntax, semantics, integrity rules, inference/derivation rules, and also a set of standard Viewpoints. Well-known modeling languages that can be formalized as Linked.Archi metamodels include UML, BPMN, ArchiMate, C4, E/R, and SQL Schema. These are domain-level languages whose concepts become arch:Element and arch:QualifiedRelationship subclasses in the knowledge graph. Note: RDF/OWL/SHACL/SKOS is the representation framework in which all the above modeling languages are expressed — it operates at the meta-meta level, not as a peer of UML or BPMN. Listing OWL alongside UML as a "modeling language" is technically defensible (OWL can model domains), but in the Linked.Archi context OWL is the substrate, not a sibling. The OMG Ontology Definition Metamodel (ODM, formal/2014-09-02) explicitly defines the mapping between MOF/UML and OWL/RDF, confirming that RDF/OWL is the layer below MOF-based languages that enables their semantic integration. A model is said to conform to a modeling language. ISO/IEC/IEEE 42010 Architecture Description can be based on a specific metamodel, which can be a simple metamodel or an aggregate of multiple metamodels from different domains. A Metamodel is a manifest that ties together all constituent resources: the model concepts ontology, SHACL shapes, derivation rules, viewpoints, taxonomy, deliverable templates, and other artifacts. It is the entry point for tools that need to discover everything that makes up a modeling language.
is in domain of
architectureViewpoints op, architectureViewpointsRestrictions op, conceptClassification op, definedByFramework op, derivationRules op, formalRules op, hasDeliverableTemplate op, metamodelIdentifiesConsideration op, metamodelIdentifiesStakeholder op, modelConcepts op, presentationContextScheme op, referenceData op, referenceModels op, standardsInformationBase op, viewpointLibrary op
is in range of
modelConformsToMetamodel op

Modelc back to ToC or Class ToC

IRI: https://meta.linked.archi/core#Model

A model is a selective representation of some system whose form and content are chosen based on a specific set of concerns. The model is related to the system by an explicit or implicit mapping. ISO/IEC/IEEE 42010 <b>Architecture Description</b> is an example of a Model, which can be a simple model or an aggregate of multiple models from different domains. The scope and context of a Model is established by analysing the domain subject area and defined by the Metamodel. High-level domains may include: * Telecommunications * Healthcare * Retail * Manufacturing * Transportation * Defense * Government More precise domains within a particular organization may be related to the different organizational bodies and depertments such as * Enterprose Architecture * Solution Architecture * Security Architecture, * Software Engineering * Operational Services * Business Departments...
is in domain of
contains op, deliverableTemplateUsed op, modelAddressesConsideration op, modelConformsToMetamodel op, modelExpressesArchitecture op, modelHasPurpose op, modelRepresentsSystem op
is in range of
partOfModel op, stakeholderHasInterestIn op

ModelConceptc back to ToC or Class ToC

IRI: https://meta.linked.archi/core#ModelConcept

ModelConcept is the base Class for all Concepts used in an Architecture [Model](#Model), namely: * [Element](#Element) * [QualifiedRelationship](#QualifiedRelationship) * [View](#View) More specific type of construct can be defined by extending this Class. Usually one will not need to use this Class directly, but mostly each of the subclasses. Custom Model Concepts are defined in the [Metamodel](#Metamodel). The palette of available concepts for a modeling tool is built from subclasses of Element (for nodes) and subclasses of QualifiedRelationship (for edges). Both carry visual notations, taxonomy classifications, and domain/range guidance.
has sub-classes
Element c, QualifiedRelationship c, View c
is in domain of
Concept Owner op, Master Data Source op, alternative Visual Notation op, associatedStandard op, exposedInView op, hasPart op, hasQualifiedRelationship op, partOf op, partOfModel op, preferred Visual Notation op, refinedInto op, refines op
is in range of
hasPart op, includesConcept op, partOf op, refinedInto op, refines op, source op, target op

Perspectivec back to ToC or Class ToC

IRI: https://meta.linked.archi/core#Perspective

Stakeholder Perspective. Example: * strategic * capability * operations * services * physical
Example
* strategic
* capability
* operations
* services
* physical
has super-classes
Consideration c
is in domain of
resultsIn op
is in range of
stakeholderHasPerspective op, viewpoint from perspective op

PresentationFormatc back to ToC or Class ToC

IRI: https://meta.linked.archi/core#PresentationFormat

Defines the output format for rendering a deliverable — e.g., Markdown, HTML, PDF, slides, dashboard. A DeliverableTemplate specifies which formats it supports via arch:templateHasFormat.
Example
* Markdown
* HTML
* PDF
* Slide Deck (PPT)
* Interactive Dashboard
is in domain of
generatorCommand dp, templateResource dp
is in range of
templateHasFormat op

Purposec back to ToC or Class ToC

IRI: https://meta.linked.archi/core#Purpose

As a work product, an AD is devised for the specific purpose for which the architecting effort is undertaken. This purpose shapes the AD and also act as force in the architecting effort. This is the same as "Design Objectives" mentioned in ADD 3.0.
Example
For a presales proposal architecture work involves rapid design. Here the main viewpoint would
        be high level structure and behaviour as well as cost estimations. The design work will not go in details
is in domain of
:purposeRequiresViewpoints op, :purposeRequiresViewpoints op
is in range of
modelHasPurpose op, templateTargetsPurpose op, viewpointHasPurpose op

QualifiedRelationshipc back to ToC or Class ToC

IRI: https://meta.linked.archi/core#QualifiedRelationship

A first-class architectural resource that represents a named, addressable relationship occurrence between two [ModelConcept](#ModelConcept) resources. QualifiedRelationship instances are genuine architectural objects — they have identity, lifecycle, provenance, governance state, and can themselves be the source or target of other relationships (higher-order modeling). Each QualifiedRelationship carries: * [source](#source) — the source element * [target](#target) — the target element The unqualified predicate is determined from: * the class definition via [unqualifiedForm](#unqualifiedForm) (schema-level) * the reified triple via rdf:reifies (instance-level, RDF 1.2) Three complementary representations are emitted for every relationship: 1. **Direct triple** — `source vocab:serves target` — for SPARQL traversal 2. **Qualified predicate** — `source vocab:qualifiedServes relationshipNode` — to navigate to the full resource 3. **Qualified relationship resource** (this class) — carries all metadata: labels, provenance, lifecycle, etc. 4. **rdf:reifies** — bridges the direct triple to this resource (RDF 1.2) With RDF 1.2, `rdf:reifies` bridges the direct triple to this resource, replacing the older rdf:Statement approach. Multiple distinct reifiers for the same proposition are supported — essential when the same logical relation appears in different contexts (current vs target state, observed vs inferred, CMDB-discovered vs design-reviewed). Subclasses of QualifiedRelationship are defined in the metamodel for each specific relationship type. The schema-level mapping to the unqualified predicate is declared using [unqualifiedForm](#unqualifiedForm). The generic fallback predicate [hasQualifiedRelationship](#hasQualifiedRelationship) is used when no type-specific qualified predicate is mapped.
Example
# Metamodel: define the relationship type
am:serves
    a                    owl:ObjectProperty ;
    skos:prefLabel       "Serves"@en ;
    arch:domainIncludes  am:ApplicationService ;
    arch:rangeIncludes   am:BusinessProcess ;
.

am:Serving
    a                    owl:Class ;
    rdfs:subClassOf      arch:QualifiedRelationship ;
    arch:unqualifiedForm am:serves ;
    skos:prefLabel       "Serving"@en ;
    arch:prefVisNotation "https://ex.com/serves.svg" ;
.

am:qualifiedServes
    a                    owl:ObjectProperty ;
    rdfs:range           am:Serving ;
    arch:unqualifiedForm am:serves ;
.

# Model data: emit both representations
ex:AppSvc1 am:serves ex:BizProc1 .

ex:AppSvc1 am:qualifiedServes ex:qr-005 .
ex:qr-005 a am:Serving ;
    arch:source ex:AppSvc1 ;
    arch:target ex:BizProc1 ;
    rdf:reifies <<( ex:AppSvc1 am:serves ex:BizProc1 )>> ;
    prov:wasDerivedFrom ex:diagramEdge-81 .
has super-classes
ModelConcept c
is in domain of
source op, target op
is in range of
hasQualifiedRelationship op

Stakeholderc back to ToC or Class ToC

IRI: https://meta.linked.archi/core#Stakeholder

:Stakeholder is the class for Stakeholders used in describing high level architecture interest. Stakeholder is a first-class element and represented in the Code ontology as it affects directly the way the architecture and architecture description will be organized and thus impact the MetaModel. Stakeholder can be used also as a :ModelConcept and for that :Element can be extended. Same instance of :Stakeholder and :element can be used and this also recommended as will benefit the analysis and inference. Example Types of stakeholders: a) Users of the system b) Acquirers of the system c) Developers of the system d) Maintainers of the system
has super-classes
Element c
is in domain of
stakeholderHasConcern op, stakeholderHasInterestIn op, stakeholderHasPerspective op
is in range of
Concept Owner op, metamodelIdentifiesStakeholder op, viewpointTargetsStakeholder op

Systemc back to ToC or Class ToC

IRI: https://meta.linked.archi/core#System

The subject of interest of a Model that is a combination of interrelated and interdependent parts organized to achieve one or more stated purposes. As such a system is defined by its structure and purpose. A system is influenced by its environment and may be bounded by space and time. This is inclusive of designs at all levels such as an entire enterprise, a process, information structures or I.T. systems.
is in domain of
environment op, meetsPurpose op, systemHasArchitecture op
is in range of
modelRepresentsSystem op, stakeholderHasInterestIn op

TemplateSectionc back to ToC or Class ToC

IRI: https://meta.linked.archi/core#TemplateSection

An ordered section within a DeliverableTemplate that references a Viewpoint. When the template is instantiated, each TemplateSection becomes a placeholder for a View conforming to the referenced viewpoint. Sections carry an order index for sequencing and optional guidance text.
Example
archvp:ADDSection1 a arch:TemplateSection ;
    arch:sectionOrder 1 ;
    arch:sectionViewpoint amvp:Organization ;
    skos:prefLabel "1. Organizational Structure"@en ;
    skos:definition "Document the organizational structure using the Organization Viewpoint."@en .
is in domain of
sectionOrder dp, sectionQuery dp, sectionResultKey dp, sectionViewpoint op
is in range of
templateHasSection op

Viewc back to ToC or Class ToC

IRI: https://meta.linked.archi/core#View

Architecture View is a representation of a system from the perspective of a related set of concerns. It consists of one or more architecture models of the system
has super-classes
ModelConcept c
has sub-classes
Catalog c, Diagram c, Matrix c
is in domain of
viewConformsToViewpoint op
is in range of
contains op, exposedInView op

Viewpointc back to ToC or Class ToC

IRI: https://meta.linked.archi/core#Viewpoint

An architecture Viewpoint is a specification of the conventions for a particular kind of architecture view. It can also be called the definition or schema for that kind of architecture view. It establishes the conventions for constructing, interpreting, and using an architecture view to address a specific concern (or set of concerns) about a system-of-interest. A viewpoint can be seen as a diferent perspective of the subject area that shapes the Metamodel, which defines the Model. Viewpoints may look quite different so as to be meaningful to different stakeholders
is in domain of
includesConcept op, view type op, viewpoint covers aspect op, viewpoint from perspective op, viewpointFramesConcern op, viewpointHasPurpose op, viewpointTargetsStakeholder op
is in range of
:purposeRequiresViewpoints op, :purposeRequiresViewpoints op, sectionViewpoint op, templateRequiresViewpoint op, viewConformsToViewpoint op

Object Properties

:purposeRequiresViewpointsop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#purposeRelevantViewpoint

:purposeRequiresViewpoint is used to model the relevant or recommended Viewpoints when performing an architecture work with the specific :Purpose
has domain
Purpose c
has range
Viewpoint c

:purposeRequiresViewpointsop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#purposeRequiresViewpoint

:purposeRequiresViewpoint is used to model the required Viewpoints when performing an architecture work with the specific :Purpose
has domain
Purpose c
has range
Viewpoint c

alternative Visual Notationop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#altVisNotation

A resource can have more than one value of :altVisNotation
has super-properties
image op
has domain
concept c
domain includes
ModelConcept c
has range
image object c

architectureViewpointsop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#architectureViewpoints

architectureViewpoints property specifies the ontology that defines the architecture viewpoints including Concerns and Stakeholders and also restriction on the viewpoints.
has domain
Metamodel c
has range
ontology c

architectureViewpointsRestrictionsop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#architectureViewpointsRestrictions

architectureViewpoints property specifies the ontology that defines restriction on the viewpoints using SHACL or other method. This can also be used for SHACL processors.
has super-properties
shapes graph op
has domain
Metamodel c
has range
ontology c

associatedStandardop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#associatedStandard

has domain
ModelConcept c
has range
creative work c
is also defined as
named individual

Concept Ownerop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#conceptOwner

Indicates the stakeholder or governance body responsible for the maintenance and governance of an architecture concept within the architecture repository.
editorial note
Use this property to explicitly document ownership to avoid ambiguity in governance responsibilities across various organisational units or roles.
has domain
ModelConcept c
has range
Stakeholder c

conceptClassificationop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#conceptClassification

ConceptClassification resource is a Scheme that defines the classification of the Elements, Relationships and Viewpoints or other Model Concepts defined within a Metamodel or ontology for example: `rdf:type skos:ConceptScheme , owl:Ontology` is a consistent statement This classification could be used for visual aid and modelling. More than one classifications can exist. Classifications can be embedded within the Metamodel ontology. SKOS concept scheme(s) needs to be supplied.
has domain
Metamodel c
has range
concept scheme c

containsop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#contains

Links a Model to the Views it contains. A Model (architecture description) is a deliverable that aggregates multiple Views, each conforming to a Viewpoint.
has domain
Model c
has range
View c

definedByFrameworkop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#basedOnFramework

The :Framework that is used as a foundation for the :MetaModel
has super-properties
had primary source op
has domain
Metamodel c
has range
Framework c

deliverableTemplateUsedop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#deliverableTemplateUsed

Links a Model (concrete deliverable) to the DeliverableTemplate it was instantiated from. This enables traceability from a deliverable back to its template and validation that all required viewpoints have corresponding views.
has domain
Model c
has range
DeliverableTemplate c

derivationRulesop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#derivationRules

DerivationRules property specifies the document that defines the possible derivation rules. A way to express those rules could be N3 notation. This can also be used for SHACL processors.
has super-properties
shapes graph op
has domain
Metamodel c
has range
ontology c

environmentop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#environment

System Situated In Environment which System and Environment interact some way or another.
has domain
System c
has range
Environment c

exposedInViewop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#exposedInView

Concepts property that specifies the individual Views that exposes that Concept such as Elements, Relationships or other Views. In the case of a relationshipRDF* or statement can be used to link the triple with the View.
has domain
ModelConcept c
has range
View c

formalRulesop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#formalRules

FormalRules property specifies all the rules that a Model needs to conform to. This include Element structure, relationships, properties even naming conventions. A way to represent those rules can be SHACL. This can also be used for SHACL processors.
has super-properties
shapes graph op
has domain
Metamodel c
has range
ontology c

hasDeliverableTemplateop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#hasDeliverableTemplate

Links a Metamodel to the DeliverableTemplates it defines. DeliverableTemplates are part of the metamodel alongside elements, relationships, viewpoints, and rules.
has domain
Metamodel c
has range
DeliverableTemplate c

hasPartop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#hasPart

hasPart

has characteristics: transitive

has domain
ModelConcept c
has range
ModelConcept c
is inverse of
partOf op

hasQualifiedRelationshipop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#hasQualifiedRelationship

Generic fallback qualified predicate used when no type-specific qualified predicate is mapped for a relationship type. Points from a source element to a QualifiedRelationship node.
has domain
ModelConcept c
has range
QualifiedRelationship c

hasQualityMeasureop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#hasQualityMeasure

Whether an element has a quality attribute measure associated to it. A domain can be an Element such as work product or behavior of a system, software, or stakeholders such as users, operators, developers, testers, or maintainers.
has domain
Element c
has range
QualityMeasure c
is inverse of
measuredEntity op

includesConceptop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#includesConcept

Defines the Concepts that may be used in this Viewpoint. These are not considered as restrictions, but can be used to define a palette of available Model Concepts. Note that more formal and rigid SHACL rules can be defined in a [shapes graph](https://w3c.github .io/data-shapes/shacl/#dfn-shapes-graphs) using property [architectureViewpointsRestrictions](#architectureViewpointsRestrictions).
has domain
Viewpoint c
has range
ModelConcept c

Master Data Sourceop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#masterDataSource

Specifies the authoritative data source or primary repository from which the architecture element's data is maintained, exported, or synchronised.
editorial note
Maintain clarity in source identification to enhance data reliability and simplify maintenance and integration workflows within the architecture repository.
has domain
ModelConcept c
has range
dataset c

measuredEntityop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#measuredEntity

Links a QualityMeasure to the Element it measures.
has domain
QualityMeasure c
has range
Element c
is inverse of
hasQualityMeasure op

measuredQualityAttributeop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#measuredQualityAttribute

Links a QualityMeasure to the QualityAttribute it quantifies.
has domain
QualityMeasure c
has range
QualityAttribute c

meetsPurposeop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#meetsPurpose

The purpose of the System. This is a generic property and can be anything.
has domain
System c
has range
thing c

mentionedInop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#mentionedIn

is inverse of
mentions op
is also defined as
annotation property

metamodelIdentifiesConsiderationop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#metamodelIdentifiesConsideration

Links a Metamodel to the Considerations it identifies as relevant for architecture descriptions using this language.
has domain
Metamodel c
has range
Consideration c

metamodelIdentifiesStakeholderop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#metamodelIdentifiesStakeholder

Links a Metamodel to the Stakeholders it identifies as relevant. Derived from ISO/IEC/IEEE 42010.
has domain
Metamodel c
has range
Stakeholder c

modelAddressesConsiderationop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#modelAddressesConsideration

Links a Model to the Considerations (concerns, aspects, perspectives) it addresses. Derived from ISO/IEC/IEEE 42010.
has domain
Model c
has range
Consideration c

modelConceptsop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#modelConcepts

ModelConcepts property specifies the Ontology that defines the structure, terms, notations, semantics and basic syntax of the modeling language. This includes Elements and Relationships subtypes. Viewpoints are defined using [architectureViewpoints](#architectureViewpoints) property and classified using [viewpointLibrary](#viewpointLibrary) property. Note actual individulas Elements, Relationships, Views are defined in the actual Architecture Model.
has domain
Metamodel c
has range
ontology c

modelConformsToMetamodelop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#modelConformsToMetamodel

Links a Model to the Metamodel (modeling language) it conforms to. A model is expressed using the vocabulary and rules defined by its metamodel. Derived from ISO/IEC/IEEE 42010 "architecture description language".
has domain
Model c
has range
Metamodel c

modelExpressesArchitectureop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#modelExpressesArchitecture

Links a Model (architecture description) to the Architecture it expresses. An architecture description is a work product that expresses an architecture. Derived from ISO/IEC/IEEE 42010.
has domain
Model c
has range
Architecture c

modelHasPurposeop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#modelHasPurpose

Links a Model to its Purpose — the reason the architecture work is undertaken.
has domain
Model c
has range
Purpose c

modelRepresentsSystemop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#modelRepresentsSystem

Links a Model to the System it represents. In ISO/IEC/IEEE 42010, an architecture description identifies a system of interest.
has domain
Model c
has range
System c

partOfop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#partOf

partOf is a generic property that is mainly intended for traceability and composability relations across models. While it can be used for composition relationships within a model, in many cases more specific semantics would be needed and for that new more specific relationship should be used.

has characteristics: transitive

has domain
ModelConcept c
has range
ModelConcept c
is inverse of
hasPart op

partOfModelop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#partOfModel

Concepts property that specifies the Model that contains that Concept such as Elements, Relationships or other Views. In the case of a relationship RDF-star or statement can be used to link the triple with the View. Note that Model propery of a concept can be expressed via quads.
has domain
ModelConcept c
has range
Model c

preferred Visual Notationop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#prefVisNotation

The preferred Visual Notation for a resource.

has characteristics: functional

has super-properties
image op
has domain
concept c
domain includes
ModelConcept c
has range
image object c

presentationContextSchemeop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#presentationContextScheme

presentationContextScheme contains classification of Presentation Context categories associated with presentation related concepts such as [DeliverableTemplate](#DeliverableTemplate), [altVisNotation](#altVisNotation), [prefVisNotation] (#prefVisNotation) Presentation Context can also be related to [Stakeholder](#Stakeholder) or stakeholder groups. In this way it used a 'Theme' to group those concepts and generate different visualizations and presentation structure depending on that Context
Example
* C-Level
* Business
* DevOps
* Architects
* Infra
* Security
* Data Management
has domain
Metamodel c
has range
concept scheme c

referenceDataop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#referenceData

any reference data that is relevant to the subject and can or should be referenced by any element or description within the Architecture Model or the Metamodel itself. For Reference Architectures, Models, Templates, Patterns, Tactics Reference design and implementations use [referenceModels](#referenceModels)
has domain
Metamodel c
has range
concept scheme c

referenceModelsop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#referenceModels

Concept scheme that contains any relevant reference Architectures, Models, Templates, Patterns, Tactics Reference design and implementations
has domain
Metamodel c
has range
concept scheme c

refinedByAspectop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#refinedByAspect

refined by
has domain
Concern c
has range
Aspect c

refinedIntoop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#refinedInto

refinedInto
has domain
ModelConcept c
has range
ModelConcept c
is inverse of
refines op

refinesop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#refines

domain refines range i.e. domain is a more concrete or complete representation of range. This is a traceability property intended to use within a single model or across models. I may be used as well as to related a particular :View that refines a :Element. For example a high level process may be refined by a sequence diagram.
has domain
ModelConcept c
has range
ModelConcept c
is inverse of
refinedInto op

resultsInop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#resultsIn

results in
has domain
Perspective c
has range
Concern c

sectionViewpointop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#sectionViewpoint

Links a TemplateSection to the Viewpoint it references. When the deliverable template is instantiated, a View conforming to this viewpoint is created for this section.
has domain
TemplateSection c
has range
Viewpoint c

sourceop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#source

the source element of a qualified relationship
has domain
QualifiedRelationship c
has range
ModelConcept c

stakeholderHasConcernop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#stakeholderHasConcern

Links a Stakeholder to their Concerns — the interests they have in the system and its architecture. Derived from ISO/IEC/IEEE 42010.
has domain
Stakeholder c
has range
Concern c

stakeholderHasInterestInop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#stakeholderHasInterestIn

Links a Stakeholder to the System, Architecture, or Model they have an interest in. Derived from ISO/IEC/IEEE 42010.
has domain
Stakeholder c
has range
Architecture c
Model c
System c

stakeholderHasPerspectiveop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#stakeholderHasPerspective

Links a Stakeholder to their Perspective — the viewpoint from which they consider the architecture (e.g., strategic, operational, technical).
has domain
Stakeholder c
has range
Perspective c

standardsInformationBaseop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#standardsInformationBase

has domain
Metamodel c
has range
concept scheme c
is also defined as
named individual

systemHasArchitectureop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#systemHasArchitecture

Links a System to its Architecture — the fundamental concepts or properties embodied in its elements, relationships, and design principles. Derived from ISO/IEC/IEEE 42010.
has domain
System c
has range
Architecture c

targetop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#target

the target element of a qualified relationship
has domain
QualifiedRelationship c
has range
ModelConcept c

templateHasFormatop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#templateHasFormat

Links a DeliverableTemplate to the PresentationFormat(s) it supports. Specifies how the deliverable can be rendered — e.g., Markdown, HTML, PDF, slides.
has domain
DeliverableTemplate c
has range
PresentationFormat c

templateHasSectionop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#templateHasSection

Links a DeliverableTemplate to its ordered TemplateSection instances. Each section references a viewpoint and carries an order index for sequencing. Use this property when section ordering and per-section guidance matter. For a simpler flat list of required viewpoints, use arch:templateRequiresViewpoint.
has domain
DeliverableTemplate c
has range
TemplateSection c

templateRequiresViewpointop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#templateRequiresViewpoint

Links a DeliverableTemplate to the Viewpoints it requires. Each referenced viewpoint acts as a placeholder — when the template is instantiated into a concrete deliverable (arch:Model), a View conforming to each required viewpoint must be created. For ordered sections with sequence numbers and guidance text, use arch:templateHasSection with TemplateSection instances instead.
has domain
DeliverableTemplate c
has range
Viewpoint c

templateTargetsPurposeop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#templateTargetsPurpose

Links a DeliverableTemplate to the Purpose(s) it supports. Indicates what kind of architecture activity the deliverable is designed for.
has domain
DeliverableTemplate c
has range
Purpose c

view typeop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#viewType

Specifies the type(s) of view a viewpoint typically produces. Values are arch:View subclasses (arch:Diagram, arch:Catalog, arch:Matrix).
has domain
Viewpoint c

viewConformsToViewpointop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#viewConformsToViewpoint

viewpoint property specifies the Viewpoint individual of a particular View instance
has domain
View c
has range
Viewpoint c

viewpoint covers aspectop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#viewpointCoversAspect

Which structural aspect(s) the viewpoint covers — e.g., Active Structure, Behavior, Passive Structure, Motivation, Composite. Values are instances of arch:Aspect.
has super-properties
viewpointFramesConcern op
has domain
Viewpoint c
has range
Aspect c

viewpoint from perspectiveop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#viewpointFromPerspective

Which stakeholder perspective(s) the viewpoint is designed for — e.g., Strategic, Operational, Application, Infrastructure, Governance. Values are instances of arch:Perspective.
has super-properties
viewpointFramesConcern op
has domain
Viewpoint c
has range
Perspective c

viewpointFramesConcernop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#viewpointFramesConcern

Links a Viewpoint to the Considerations it addresses. This is the generic property — use the sub-properties :viewpointCoversAspect and :viewpointFromPerspective for more specific queries on which structural aspect or stakeholder perspective a viewpoint covers.
has sub-properties
viewpoint covers aspect op, viewpoint from perspective op
has domain
Viewpoint c
has range
Consideration c

viewpointHasPurposeop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#viewpointHasPurpose

Links a Viewpoint to its purpose — the type of architecture activity it supports. Common purposes include Deciding (evaluating options, portfolio rationalization), Designing (creating or refining architecture), Informing (communicating to stakeholders), and Governing (compliance checking, standards enforcement).
has domain
Viewpoint c
has range
Purpose c

viewpointLibraryop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#viewpointLibrary

viewpointLibrary property specifies a Concept scheme that classifies available Viewpoints
has domain
Metamodel c
has range
concept scheme c

viewpointTargetsStakeholderop back to ToC or Object Property ToC

IRI: https://meta.linked.archi/core#targetsStakeholder

Viewpoint property that relates targeted stakeholders. While this relationship can be infered from :viewpointFramesConcern and :stakeholderHasConcern it is not always the case when concerns overlap or there are different visual notations and representation preferences form the side of the stakeholders. In other words this is explicitly defined by the designer of the particular viewpoint and can match all or a subsets of the stakeholders. In some case it
has domain
Viewpoint c
has range
Stakeholder c

Data Properties

generatorCommanddp back to ToC or Data Property ToC

IRI: https://meta.linked.archi/core#generatorCommand

The shell command or pipeline used to produce the deliverable output from the knowledge graph and the template resource. The command receives the SPARQL endpoint or data file as input and produces the rendered output.
Example
"handlebars render --template aod.md.hbs --data sparql://localhost:7200"
"python generate.py --format pdf --template governance.tex"
"mkdocs build --config-file mkdocs-deliverable.yml"
has domain
PresentationFormat c
has range
string

isAbstractdp back to ToC or Data Property ToC

IRI: https://meta.linked.archi/core#isAbstract

Denotes if an element is abstract or concrete. These can be respectively Architecture Building Block (ABB) or Solution Building Block (SBB). SBBs are used for concrete architecture solutions and are normaly part of a catalogue and exists in CMDB ot ITSM solutions as well as architecture landscape repository. ABBs are more abstract and used for modellig patterns, reference architectures or hight level (superior) architectures
has domain
Element c
has range
boolean

sectionOrderdp back to ToC or Data Property ToC

IRI: https://meta.linked.archi/core#sectionOrder

The ordinal position of a TemplateSection within its DeliverableTemplate. Sections are ordered by ascending sectionOrder value.
has domain
TemplateSection c
has range
integer

sectionQuerydp back to ToC or Data Property ToC

IRI: https://meta.linked.archi/core#sectionQuery

A SPARQL SELECT or CONSTRUCT query that extracts the data needed to populate this template section from the knowledge graph. The query is executed against the architecture model data and its results are passed to the template engine as the data context for this section. Variable names in the SELECT clause become JSON keys in the template context. For example, a query returning ?label and ?description produces objects with "label" and "description" fields that the Handlebars template iterates over. This property makes the deliverable generation pipeline fully declarative: a tool reads the template sections in order, executes each section's query, and renders the template with the results. No hardcoded extraction logic is needed.
Example
:ADD-S1 arch:sectionQuery """
    PREFIX am: <https://meta.linked.archi/archimate3/onto#>
    PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
    SELECT ?label ?description WHERE {
        ?actor a am:BusinessActor ;
               skos:prefLabel ?label .
        OPTIONAL { ?actor skos:definition ?description }
        FILTER(lang(?label) = "en")
    } ORDER BY ?label
"""^^xsd:string .
has domain
TemplateSection c
has range
string

sectionResultKeydp back to ToC or Data Property ToC

IRI: https://meta.linked.archi/core#sectionResultKey

The JSON key under which the query results for this section are placed in the template context. For example, if sectionResultKey is "businessActors", the Handlebars template accesses the data via {{#each businessActors}}. If not specified, a tool may derive the key from the section's local name or sectionOrder.
Example
"businessActors", "crossLayerRelationships", "requirements"
has domain
TemplateSection c
has range
string

templateResourcedp back to ToC or Data Property ToC

IRI: https://meta.linked.archi/core#templateResource

Points to the actual template file, URL, or resource used to render a deliverable in this format. Can be a local file path, a URL to a template repository, or a reference to a template engine resource (e.g., Handlebars, Jinja2, XSLT).
Example
"templates/aod.md.hbs"          — Handlebars Markdown template
"templates/report.html.j2"      — Jinja2 HTML template
"templates/governance.tex"       — LaTeX PDF template
"https://templates.linked.archi/slides/default.pptx" — remote PPTX template
has domain
PresentationFormat c
has range
anyURI

Named Individuals

:ni back to ToC or Named Individual ToC

IRI: https://meta.linked.archi/core#

has facts
image op la logo v1.png

associatedStandardni back to ToC or Named Individual ToC

IRI: https://meta.linked.archi/core#associatedStandard

has facts
mentionedIn op chap06.html
is also defined as
object property

MetamodelingCategoryni back to ToC or Named Individual ToC

IRI: https://meta.linked.archi/core#MetamodelingCategory

Category for concepts that define the modeling language itself — metamodels, viewpoints, and rules.
belongs to
concept c

ModelingCategoryni back to ToC or Named Individual ToC

IRI: https://meta.linked.archi/core#ModelingCategory

Category for concepts used in the modeling process — elements, relationships, and views.
belongs to
concept c

PresentationCategoryni back to ToC or Named Individual ToC

IRI: https://meta.linked.archi/core#PresentationCategory

Category for concepts related to visual presentation — notations, templates, and rendering.
belongs to
concept c

QualityAttributeni back to ToC or Named Individual ToC

IRI: https://meta.linked.archi/core#QualityAttribute

has facts
mentionedIn op quality attributes
is also defined as
class

QualityMeasureni back to ToC or Named Individual ToC

IRI: https://meta.linked.archi/core#QualityMeasure

has facts
mentionedIn op quality attributes
is also defined as
class

standardsInformationBaseni back to ToC or Named Individual ToC

IRI: https://meta.linked.archi/core#standardsInformationBase

has facts
mentionedIn op chap06.html
is also defined as
object property

Legend back to ToC

c: Classes
op: Object Properties
dp: Data Properties
ni: Named Individuals

Changes from last version

Acknowledgments back to ToC

The authors would like to thank Silvio Peroni for developing LODE, a Live OWL Documentation Environment, which is used for representing the Cross Referencing Section of this document and Daniel Garijo for developing Widoco, the program used to create the template used in this documentation.